Re: Java "security holes'

To: dhudes@panix.com (Dana Hudes)
Subject: Re: Java "security holes'
From: Adam Shostack <adam@bwh.harvard.edu>
Date: Wed, 13 Mar 1996 12:30:10 -0500 (EST)
Cc: www-security@ns2.rutgers.edu
In-Reply-To: <Pine.SUN.3.91.960312152328.20586C-100000@panix.com> from "Dana Hudes" at Mar 12, 96 03:31:36 pm

Dana Hudes wrote:

| On Tue, 12 Mar 1996, Adam Shostack wrote:
| > 
| > 	One of the important functions of a firewall is to allow
| > centralization of policy decisions.  Thus, if I have a firewall that
| > (for example) allows http and forbids telnet out, that is likely a
| > policy decision on the part of the organization.  If there is a
| > telnet in java that allows me to run a telnet connection through the
| > http proxy, then my policy has been nullified by user actions.
| 
| But this is not what Java does. Maybe I'm confused here but I understood 
| the question of opening connections to arbirtrary destinations to be 
| forbidden, which is what I am against. A java app trying to telnet 
| somewhere is not using http -- although I suppose a malicious app could 
| open a socket on  tcp port 80 to craccker central which is listening with 
| the cracker_record daemon rather than httpd. More paranoid is to open a 
| socket to cracker central and use http post to record the stolen 
| information. That would be hard to detect by a packet-examining firewall.

	You're for allowing Java code (any Java code on the net?) to
open a socket to any machine on the internet?

	I was using telnet over http as an example of the kind of
'bypass the firewall' code that could be written, and provided to
users.  "Forgive them, they know not what they do."

	Again, the difference between Java and C code in this regard
is that gunzip, tar, configure and make are actually beyond what many
users are willing or able to undertake.

| > 	A good firewall will continue to work at some level even when
| > users try to subvert it.  As such, there needs to be another level of
| > thinking besides user, which is the organization, which sets policies
| > ("No Java except as signed by Verisign", or "No Javascript") which are
| > then forced on the user.
| > 
| > 	Otherwise, users will be tricked into running malicious code
| > "This really neat Trek app turns your Eudora 'You have new mail'
| > screen into United Federation of Planets spalsh graphic!  But you need
| > to give Java full access to let it run."
| > 
| > 	The Java applet that does this differs from the downloadable
| > program that does this in that the downloadded program isn't expected
| > to open IP connections to the outside world, whereas the Java applet
| > is.
| 
| I like the concept of delgating control to the security/admin authorities
| but note that everyone is busily d/l Mosaic, Netscape etc which not only 
| open arbirtary locations but use all sorts of protocols and even tunnel 
| through firewalls with SOCKS. How do you know that Mosaic or Netscape 
| is not attacking, quietly, your network and passing the info on to 
| cracker.mcom.com?

	I trust Mosiac isn't because I've read most of the code.  I
trust Netscape because if they're snooping my site it would show up in
firewall logs, and I would sue their pants off.  With Java, I can't
review the code, and I can't sue the author, who is an anonymous high
school student in Bulgaria.

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

References:

Re: Java "security holes'

From: Dana Hudes <dhudes@panix.com>